Cette version 1.0 implémente l'API Silverlight 1.0 (avec une compatibilité avec la pile multimédia 2.0 - moins le support DRM). L'implémentation passe toutes les suites de tests de régression de Microsoft et est distribuée avec les packs Multimédia de Microsoft pour architectures x86 et x86-64.
Moonlight 1.0 est écrit en C++ et ne contient pas l'environnement d'exécution ECMA CLI. L'interaction avec le greffon se fait en utilisant le moteur Javascript du navigateur. Moonlight est distribué sous la licence LGPL v2.
Avec Silverlight 2.0 (et dans le futur Moonlight 2.0), un nouveau modèle d'interaction est disponible sous la forme d'un environnement d'exécution .Net, permettant d'interagir avec le greffon en utilisant n'importe quel langage supporté par .Net (C#, VB#, Boo, IronRuby, IronPython, ...).
Aller plus loin
- Télécharger Moonlight (34 clics)
- Blog de Miguel de Icaza (7 clics)
- Blog de Scott Guthrie (Corporate Vice President, .Net developer Division, Microsoft) (4 clics)
- Blog de Scott Hanselman (4 clics)
- Application Video.Show de Vertigo pour tester (5 clics)
- Sondage pour support multimédia sur autres plates-formes Unix (6 clics)
# Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Ok, la technologie est ouverte, apparemment il ne plane plus ou peu de menaces en ce qui concerne les brevets (suis pas tout-à-fait au point là dessus cela dit), certes, why not. Et techniquement c'est costaud.
Cela dit, programmer dans le libre, c'est essentiellement une question d'envie, d'appétence, et pas seulement une question technique. Comment attirer une communauté, dont la philosophie générale compte lors de l'adoption d'une techno, pour un produit qui est une implémentation d'un truc venant d'une des sociétés les plus méprisante vis à vis du libre ?
J'ai fait personnellement du C# il y a quelques années et j'ai techniquement apprécié. Ce qui m'a fait arrêter c'est cette drôle de sensation. Un peu comme si on mangeait un excellent filet de perche du Nil. L'impression de participer à quelque chose dont l'origine me gêne...
Vous me répondrez "bin lis pas la news et passe ton chemin" et vous auriez raison. Mais c'est vendredi et ma maman a dit que je pouvais :)
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Steven Le Roux . Évalué à 8.
Je sais pertinemment que je n'irai pas installer ce plugin... aussi parce que je ne vais pas me plier au caprice d'un géant qui arrive une fois la course terminée comme d'habitude, mais qui va, par tous les moyens, tenter d'imposer sa solution à coût de dollars vers quelques sites web clés.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Larry Cow . Évalué à 4.
D'un autre côté, vu le nombre de projets libres en Java, l'appétence n'est pas tant un problème que ça.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par windu.2b . Évalué à 10.
* Sun libère Java sous licence GPL (c'est pas fini, c'est pas complet mais y a déjà du concret) ;
* Java a toujours été multi-plateforme, et c'est Sun qui a fait le travail. Pour C#/.Net/Silverlight/... MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Larry Cow . Évalué à 4.
C'est assez récent, et les projets libres en Java ne sont pas un phénomène récent.
* Sun a bien moins une réputation d'anti-libre que MS ;
et
* Java a toujours été multi-plateforme, et c'est Sun qui a fait le travail. Pour C#/.Net/Silverlight/... MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
Correct. Rien à redire. Si ce n'est que ce n'est pas tant sur l'aspect "libre" de Java que mon "appeal-detector" tiquait. J'étais plus sur le langage lui-même : sa syntaxe, les pratiques qui lui sont associées, etc.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par windu.2b . Évalué à 3.
Là par contre, j'ai pas compris...
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Larry Cow . Évalué à 7.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . Évalué à 7.
Vu que c'est vendredi, je me permettais de faire remarquer que Java, c'est l'antithèse du langage "attirant" : verbeux en diable, favorisant des cycles de développement poussifs, nécessitant un environnement de développement lourdingue, générant des applications mal intégrées à leur entourage, etc.
Ayant eu aujourd'hui à maintenir un bout de code ruby pourtant pas crade, je peut te dire qu'il existe des langages bien pires que Java.
J'avais oublié à quel point le duck typing ca faisait faire coin coin a ton programme quand il s'exécute et qu'il passe a l'endroit ou tu as oublié de changer le nom d'une fonction renommée, ou encore le bonheur de pas avoir une exception de levée lors d'un dépassement d'index dans un tableau
Pour faire des scripts pas trop gros cela dit c'est sympa ruby
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Larry Cow . Évalué à 1.
Certes (brainfuck et goto++, c'est pas pour les chiens), mais Java est probablement le plus mauvais rapport "agrément/chance de tomber dessus".
J'avais oublié à quel point le duck typing ca faisait faire coin coin a ton programme quand il s'exécute et qu'il passe a l'endroit ou tu as oublié de changer le nom d'une fonction renommée,
Je connais très mal Ruby (voire pas du tout), mais quel rapport entre le duck-typing (ou fait de juger du type d'un "truc" en fonction de ses capacités/caractéristiques utiles plutôt que selon une déclaration préalable) et ton problème de symbole introuvable (qui si je ne m'abuse aurait été réglé tout seul par un "refactor" automatisé)?
ou encore le bonheur de pas avoir une exception de levée lors d'un dépassement d'index dans un tableau
Encore une fois, Ruby n'est pas tellement mon domaine, et je n'irais pas le défendre bec et ongles. M'enfin ça me paraît fou qu'il ne gère pas un truc pareil.
Mais bon, si on va par là, les langages qui imposent aux exceptions d'être des classes, alors que la plupart du temps une simple chaîne suffirait amplement...
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . Évalué à 4.
Pour le coup du tableau en ruby, je suis peut etre fou, mais pourtant ce code ne génère pas d'erreur :
#!/usr/bin/ruby
array=[1,2]
print array[999]
#./test.rb
nil
Quand aux exceptions qui sont des classes je vois pas trop le probleme.
Ca doit etre surement moins couteux à l'execution et ca permet de vérifier le type d'erreur de maniere efficace et maintenable (en cas de renommage de l'exception le compilo te gueule dessus).
Je n'arrive pas à y voir d'inconvénient évident.
Ca va paraitre trollesque, mais quand je dois coder un truc dans ce genre de langages, j'ai un peu l'impression de faire un grand retour dans le temps à la glorieuse époque du VB6, sans le "OPTION EXPLICIT" bien sur
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Psychofox (Mastodon) . Évalué à 4.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Thomas Douillard . Évalué à 4.
En gros, en java, si tu fais un dépassement de capacité sur un tableau, le programme te plantera immédiatement à la gueule en te disant "eh ! t'as dépassé la capacité du tableau".
En ruby, ton programme continuera un moment de tourner, et plantera potentiellement (ou pas) plus loin, et l'erreur sera donc potentiellement nettement plus difficile à remonter.
Après bien sûr t'as des bonnes pratiques pour éviter ça, utiliser des collection et des iterateurs, tester des trucs, mais en cas d'erreur, ce qui arrive à tout le monde, tu vois la différence pour débugger ce genre de langages.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . Évalué à 4.
Java te renvoie une exception, tu vois qu'il y a eu dépassement (et ou il a eu lieu), tu te retrouves avec un bon point de départ pour corriger le bug.
Ruby fait planter le programme autre part à cause d'un nil (ou encore pire lui fait produire des résultats faux), tu peux passer du temps à chercher l'erreur.
Pour avoir codé dans les deux langages je peut dire que le comportement de java dans ce cas simplifie beaucoup plus la vie du développeur
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Psychofox (Mastodon) . Évalué à 3.
Quand je manipule un tableau sous ruby, je pars du principe qu'il n'a pas de taille finie. C'est effectivement bien plus compliqué à gérer.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . Évalué à 1.
il convient surtout de garder en tête la méthode size pour éviter ce genre d'erreurs.
Faut arreter, mettre une condition sur l'index a la main avant chaque acces a un tableau pour détecter une erreur de programmation, ca frole le ridicule.
Ou alors tu voulais dire autre chose ?
[^] # Code le toi même
Posté par Jean B . Évalué à 2.
a = []
puts a[42] #=> nil
class Array
def get!(index)
val = self[index]
raise IndexError if val.nil?
return val
end
end
puts a.get!(42) #=> IndexError
[^] # Re: Code le toi même
Posté par thedude . Évalué à 3.
[^] # Re: Code le toi même
Posté par Jean B . Évalué à 2.
Oui, mais c'est justement AHMA la grande force de Ruby. Souvent dans les troll Python/Ruby (dieu sait qu'il y en a depuis l'événement de Django et Rails) un des arguments des Pythonistes (dont je fait partie) est que la librairie standard de Ruby est incomplète et je suis assez d'accord. Seulement avec cette possibilité de monkey_patching les builtins on peut corriger ça facilement, il n'y a qu'a voir le nombre de méthode que Rails rajoute.
Quand je codais en PHP je souffrait du même comportement foireu mais je ne pouvais rien faire si ce n'est une moche fonction get_item($array, $index) ou un if a chaque accès.
Idem en Python bien qu'il soit très complet j'ai souvent envie de rajouter quelque chose. Et la a part sous classer (ce qui est génant avec les objet litéraux) on ne peut pas modifier les builts-in et a mon grand regret Python3 ne le permet pas non plus.
[^] # Re: Code le toi même
Posté par Sylvain Sauvage . Évalué à 3.
D’abord, cette fonction get! n’a pas à être dans le langage par défaut, ne serait-ce que parce que l’on peut très bien vouloir avoir des nil dans son Array. Ce n’est pas la valeur de l’élément qu’il faut tester mais si l’indice est ou non hors champ.
Mais ce n’est pas le point principal. Ce qu’il faut comprendre, c’est qu’un Array n’est pas un tableau comme en C ou en Java.
Un Array, c’est une structure de données de type collection, séquentielle et indexée, donc comme un tableau ou une liste. C’est comme un Hash mais les clefs sont des entiers et les éléments sont ordonnés dans une séquence, donc on peut récupérer des sous-séquences.
Si l’on a un Hash qui ne possède pas de valeur pour une clef (disons :toto), que h[:toto] renvoie nil vous choque ? Bien sûr que non. C’est pareil en Java (on récupère null d’une Hashmap quand la clef n’y a pas de correspondant). C’est pareil en C++ avec les std::map (on récupère une référence sur une nouvelle place).
Or on pourrait très bien vouloir que ça lance une exception IllegalKey ou autre.
C’est un choix.
En Ruby, il a été décidé que c’était pareil pour les Array : un indice hors taille renvoie nil.
Vous pouvez aussi utiliser des indices négatifs : a[-1] renvoie le dernier élément, a[-2] l’avant-dernier, etc.
Et des Range : a[1..5] donne la sous-séquence des éléments 2 à 6, ou a[1,4] qui donne la sous-séquence de 4 éléments à partir du 2e.
On pourra aussi remarquer que, souvent, là où l’on utilise un Hash, on peut utiliser un Array ou une lambda : tous les trois répondent à l’opérateur [].
Oui, c’est du Duck-Typing. Si vous voulez du typage fort, vous prenez C++ ou Java ou autre (Java, surtout si vous voulez des exceptions partout).
[^] # Re: Code le toi même
Posté par timid . Évalué à -1.
Sinon les exceptions, oui j'en veut partout, j'aime bien que mon programme m'avertisse quand quelque chose va mal au lieu de continuer à tourner silencieusement et à produire des résultats faux.
[^] # Re: Code le toi même
Posté par thedude . Évalué à 2.
Ce que tu me decrit la, c'est exactement la List de java.
Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.
Si tu ne peux pas faire un put(Object key, Object value), mais just un addItem(value) alors desole, mais c'est un tableau/liste et pas une hash map.
Si tu peux le faire, c'est que j'ai mal compris ce que tu as mal explique.
[^] # Re: Code le toi même
Posté par lasher . Évalué à 3.
Et devines quoi? La liste de java te retourne une outofbounds exception quand tu fait un get qui pousse le bouchon un peu loin.
D'un autre côté, en C++, quand tu utilises un objet de classe vector, tu as deux accès possibles :
1) v.at(i), où v renverra une exception si tu fais un dépassement, et
2) v[i], où aucune exception ne sera levée, mais qui va bien plus vite en terme de latence d'accès aux éléments du vecteur.
Il n'y a donc pas de réelle « bonne façon de faire » pour des tableaux dynamiques. Parce que les exceptions c'est très bien, c'est très pratique et tout, mais à en foutre partout, on finit par plomber les perfs à cause des indirections, de l'effet « goto » qui force à se référer plus ou moins constamment à la doc (« le "goto" c'est maaaaaaaaaaaaaaal, fais plutôt des exceptions ! »), etc.
[^] # Re: Code le toi même
Posté par thedude . Évalué à 6.
Certes, ca va ralentir un peu les perfs.
Apres, avoir un programme qui va vachement vite mais qui te retourne un resultat faux que tu sais meme pas qu'il l'est, a cause d'un bug de programmation, honnetement, ca m'avance pas des masses.
Soyons honnete, un acces en dehors des bornes, que ca te plaise ou non, ca reste une grossiere erreur de programmation dans 99,9% des cas, tu tentes d'acceder a qq chose de pas defini et ca compromet tres fortement l'integrite du code qui suit.
Tu doit etre capable de le savoir. Libre a toi d'en faire ce que tu veux apres.
Tant qu'on y est, on pourrait aussi passer sous silence la null pointer exception, les programmes iraient vachement plus vite sans.
[^] # Re: Code le toi même
Posté par lasher . Évalué à 3.
[à propos des exceptions] Certes, ca va ralentir un peu les perfs.
Non. Si tu fais un accès dans une boucle, ce n'est pas « un peu ». Alors c'est sûr, si tu comptes parcourir tout le tableau/la liste/le vecteur/etc, il vaudrait mieux utiliser un itérateur, mais parfois, on ne peut pas (la variable d'induction sert pour indexer d'autres structures, etc).
Qu'on soit bien d'accord je suis à fond pour l'utilisation de langages de haut-niveau, avec tous les mécanismes modernes qu'ils peuvent procurer, et ce le plus souvent possible. Mais il y a des fois où ils se mettent en travers de la performance, car trop présents implicitement. Dans ces cas-là, j'aimerais pouvoir « désactiver » certaines fonctionnalités (par exemple en utilisant v[i] à la place de v.at(i) en C++ :-) ) qui font que mon programme ne va pas assez vite (après avoir fait du profiling, vérifié que je ne faisais pas de la micro-optimisation pour rien, etc, bien entendu). Avant de passer à du « pur C » ou encore pire, de l'assembleur, j'aimerais bien que le langage, ou plutôt l'environnement, me laisse désactiver certains mécanismes qui me semblent superflus dans une région de code bien précise.
La façon de faire de Ruby pour l'accès aux tableaux est très semblable (identique ?) à ce que fait Perl. Quand je code en Perl, je suis conscient de ça, et c'est pour ça que j'ai les warnings à fond tout le temps, parce que l'implicite, c'est bien, mais je préfère avoir l'interpréteur qui continue de faire tourner mon code, mais qui m'avertit quand j'ai des valeurs indéfinies qui sont quand même utilisées. Ça ne bloque pas mon programme pour autant (même si souvent ça le rend "faux", ie le warning n'était pas prévu), mais parfois l'erreur que j'ai introduite n'est pas grave, au sens où le résultat que je recherche est quand même là. Bon évidemment, je finis toujours par tomber sur un cas où ça va sérieusement m'empêcher d'avancer dans mon boulot, et je dois bien arriver à faire taire ce #@! d'interpréteur qui m'avertit que je gruike un peu trop ... et donc changer mon code. :)
Concernant les NullPointerException, la différence, c'est que même en C où un programme pourrait tout à fait continuer longtemps avant de planter tout en donnant un résultat erroné, avec un pointeur NULL, ton programme plante, et c'est tout (et en ce qui me concerne, je ne fais que du C ou presque, et si j'ai un segfault, au moins je sais qu'il y a une erreur, et j'ai un point de départ pour la trouver). On aura donc du mal à la capturer. :-)
[^] # Re: Code le toi même
Posté par thedude . Évalué à 1.
- des cas tres particuliers. Comme tu le dit, l'iterateur est pas fait pour les chiens et largement preferable, le cas que tu decris, a savoir iteration sur un tableau et acces a un autre tableau a chaque iteration etant pas forcement tres courant, et tres certainement resolvable avec une structure adaptee, surtout si c'est du code qui est execute tres souvent (s'il ne l'etait pas, tu grapilles des pouillieme de poussieres de milisecondes et t'as certainement d'autres chats a fouetter).
- une optimisation qui saute juste un pauvre if (donc negligeable si ton code est complexe dans la boucle, ce qui a l'air d'etre le cas, s'il ne l'est pas et que tu te contentes d'iterer sur les valeurs, c'est ptetre que ton choxi de structure est pas topmoumoute?).
Sachant que meme si je me gourre dans mon assertion plus haut (probable :) )et que effectivement tu perds du temps dans tes boucles et que tu peux pas faire autrement, ruby est un langage interprete sans JIT (donc par nature pas franchement rapide ni meme fait pour aller un tant soit peu vite et ne laissant strictement aucune place aux optimisations du compilo), j'ai du mal a voir la pertinence de ton optimisation...
T'as l'air d'avoir cherche en profondeur avant d'en arriver a cette conclusion, donc si tu peux etayer un peu plus l'argumentation, parce que la je reste tel la fosse, sceptique.
Bref, je concois que dans un langage oriente ultra optimisation et maximum de controle a l'utlisateur (severement burne) on fasse ce genre de choses, dans un langage de script de haut niveau, c'est pour le moins etonnant et la justification me laisse sur ma faim.
[^] # Re: Code le toi même
Posté par lasher . Évalué à 2.
De plus dans le cas de code scientifique par exemple, typiquement un solveur itératif, il n'est pas rare d'avoir des accès de type
for (i=1; i<m ; ++i) {
____for (j = 1; j < n; ++j) {
________v1[i][j] += a + (v1[i][j-1] *v1[i][j+1]) + b + v1[i-1][j] * v1[i+1][j] + ...;
}
Bien entendu il s'agit d'un code factice, mais l'idée est là. On a même des cas où plusieurs vecteurs se mélangent. Dans ce cas précis j'ai pris un tableau 2D, donc le terme de « vecteur » n'est certes pas le meilleur, mais c'était pour illustrer mon propos.
Concernant mon post précédent, je faisais 2 remarques, orthogonales l'une de l'autre :
1/ Un langage n'est pas obligé d'imposer une seule façon de traiter les structures de données, pour tout un tas de raisons (et je prenais C++ en exemple, qui propose les deux mécanismes, à cause de certains problèmes de perf); de plus même si le langage n'impose qu'une seule façon (« Java »), il n'est pas dit que ce soit la seule bonne façon de faire, et la façon de gérer cela par d'autres langages n'est pas nécessairement moins mauvaise : tout dépend des objectifs qu'on se fixe.
2/ Concernant Ruby spécifiquement, renvoyer nil (ou undef en Perl) n'est pas nécessairement une mauvaise chose, et je parlais du fait que parfois j'ai une sortie « imparfaite » de mes scripts Perl, mais « suffisamment bonne » pour que je puisse quand même me servir de ces résultats, ne serait-ce que partiellement (je me sers beaucoup de Perl pour analyser la sortie de fichiers au format CSV ou pas très loin du CSV dumpés par mes programmes, et adapter les données à mes besoins). Par exemple, à cause d'une erreur de ma part, le script peut avoir raté une ligne (je n'avais pas prévu un certain type de format de ligne, et du coup mon script ne sait pas le gérer), mais le calcul en lui-même n'est pas forcément faux pour le reste des autres lignes du fichier que je veux traiter. Dans ce cas je préfère un warning qui me dit que je divise par 0, que j'essaie de faire des trucs avec une variable non-définie, etc, mais que le programme continue de tourner pour pouvoir quand même espérer détecter une tendance par exemple, plutôt qu'avoir un programme qui s'arrête parce que euh, ben, « Y'a une exception, là, et je sais pas quoi en faire, donc je stoppe tout. ».
[^] # Re: Code le toi même
Posté par timid . Évalué à 0.
2/ Pour coder un petit truc dans ton coin si tu veux, ca m'arrive de le faire moi aussi, mais imaginer faire un programme censé produire des résultats fiables pour d'autres personnes avec des outils comme ca ...
J'ai du mal a comprendre pourquoi tant de gens utilisent ces langages de script pour coder des trucs entiers. C'est pourtant assez évident que c'est un non sens.
[^] # Re: Code le toi même
Posté par thedude . Évalué à 1.
ArrayList est la classe que tu veux utiliser.
Et je suis pas sur que t'y perdes quoi que ce soit en perfs par rapport a un tableau.
Entierement d'accord sur ton second point cela dit.
[^] # Re: Code le toi même
Posté par lasher . Évalué à 3.
Et moi pas. :-)
Je me sers de langages de script pour prototyper pas mal de trucs. Pas forcément une grosse appli monstrueuse, mais le temps que je gagne à développer ces trucs (et parfois à faire de mes petits scripts des modules qui re-servent à mes collègues) fait gagner un temps fou en dév. Après, il y a aussi des fois où je fais un rapide prototype en Perl, et ensuite je code le truc pour de bon en C (parce que par exemple, j'aurai besoin d'avoir une bibliothèque qu'on puisse directement appeler).
Malgré tout, des langages comme Ruby ou Python, qui ont tout un tas de très bons mécanismes intégrés au langage, sont tout à fait viables pour faire des applis « sérieuses ». [1] Faut-il être plus vigilant du fait que ce sont des langages à typage dynamique (par exemple) ? Pas sûr, après tout, Python fait dans le typage fort, et renvoie des exceptions et tout ce qui va avec comme les autres langages de haut-niveau.
Après quelques mois de dév Java, j'ai eu au contraire l'impression inverse : le langage est tellement rigide qu'il force à faire des contorsions pas possible là où parfois il existerait des raccourcis tellement pratiques. Mais c'est le prix à payer pour un typage fort et statique, je suppose, et aussi au fait que je devenais aigri à devoir faire du Struts/Hibernate/JBoss/JSP/JSP/JSP. Surtout JSP en fait.
Quand je suis retourné à faire du Perl par la suite, tout un tas de choses compliquées en Java me semblaient quand même vachement plus simples à accomplir avec Perl.
[1] Perl aussi selon moi, mais j'avoue avoir beaucoup de mal avec la façon dont Perl gère la programmation orientée objet, du coup je ne programme que de bêtes modules pas OO.
[^] # Re: Code le toi même
Posté par Jean B . Évalué à 2.
Non ce que tu viens de décrire n'a rien a voir avec le concept de Duck Typing. Python qui a inventé la notion Duck typing te pète une erreur si tu demande un index trop grand ou te renvoie une valeur par défaut si explicitement demandé.
La c'est un choix de Ruby de faire comme Perl et PHP de renvoyer nil plutôt que péter. Le programmeur doit donc tester sinon il risque d'appeler une méthode sur nil. C'est juste une question de gout.
Et je te rappelle que Ruby que tu connais mieux que tout le monde apparemment, est un langage a typage fort tout comme Java.
[^] # Re: Code le toi même
Posté par Sylvain Sauvage . Évalué à 2.
Non ce que tu viens de décrire n'a rien a voir avec le concept de Duck Typing.
Si. Pouvoir utiliser un Hash, une Lambda ou un Array parce que tous les trois répondent à l’opérateur [], c’est du Duck Typing.
Et le fait que [] réponde nil quand la clef/l’indice n’a pas de correspondant pour un Hash ou un Array fait bien que le « coin » de l’Array est le même que celui du Hash. Même « coin », même canard.
Python qui a inventé la notion Duck typing […]
Pas vraiment. On faisait du Duck Typing avant. C’est juste que le terme a été utilisé pour décrire ce typage dans Python.
L[à] c'est un choix de Ruby de faire comme Perl et PHP de renvoyer nil plutôt que péter. Le programmeur doit donc tester sinon il risque d'appeler une méthode sur nil. C'est juste une question de gout.
C’est exactement ce que je dis : « En Ruby, il a été décidé que c’était pareil pour les Array : un indice hors taille renvoie nil. » C’est un choix.
C’est pour cela que je réponds « Non. » à ceux qui sautent à pieds joints sur la table en répétant « C’est nul, ça doit être dans le langage ! ».
Et je te rappelle que Ruby que tu connais mieux que tout le monde apparemment,
En tout cas mieux que lesdits sauteurs…
est un langage a typage fort tout comme Java.
Oui, mea culpa, lapsus calami, je voulais écrire « typage statique ».
[^] # Re: Code le toi même
Posté par Jean B . Évalué à 2.
Autant pour moi je t'avais mal compris. On a bien la même vision de la chose.
Pas vraiment. On faisait du Duck Typing avant. C’est juste que le terme a été utilisé pour décrire ce typage dans Python.
La encore je voulais parler de l'expression pas du concept. Mea culpa.
[^] # Re: Code le toi même
Posté par reno . Évalué à 1.
Sinon pourquoi "get!" et pas "get" ?
Il me semblait que le point d'exclamation est une convention de nommage pour les methodes qui modifie les objets..
[^] # Re: Code le toi même
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
[^] # Re: Code le toi même
Posté par Jean B . Évalué à 2.
Pour être franc je suis du même avis. C'est typiquement un comportement Perlien/PHPien qui cache les problèmes. Je préfère les IndexError de Python et le .get a l'occasion.
Sinon pourquoi "get!" et pas "get" ?
Il me semblait que le point d'exclamation est une convention de nommage pour les methodes qui modifie les objets..
Oui mais pas seulement. Exemple: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M0(...)
Le bang est aussi utilisé pour signaler la possible levée d'exception.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par TImaniac (site web personnel) . Évalué à 4.
.NET a toujours été multi-plateforme, MS l'a montré dès le début avec des implémentations sous mac et bsd. Ses implémentations sur périphériques embarqués le montre également.
c'est Sun qui a fait le travail
C'est effectivement la grosse différence.
MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
Pour Silverlight , MS fourni l'implémentation des codecs. Niveau dev c'est le gros du boulot.
Pour Silverlight 2.0, MS fourni la bibliothèque des widgets graphiques.
Pour .NET, MS fourni la stack DLR, la bibliothèques javascript pour ASP.NET AJAX, le compilateur IronPython.
Si ca c'est pas du dev, je sais pas ce que c'est !
Mais bon de toute façon, MS participerait au développement du coeur de Mono que ca vous ferait au contraire une raison supplémentaire de râler.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par windu.2b . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . Évalué à 6.
MS n'a jamais participé au développement (ils ont "juste" publié de la documentation pour permettre cela).
Pour Silverlight , MS fourni l'implémentation des codecs. Niveau dev c'est le gros du boulot.
Pour Silverlight 2.0, MS fourni la bibliothèque des widgets graphiques.
Pour .NET, MS fourni la stack DLR, la bibliothèques javascript pour ASP.NET AJAX, le compilateur IronPython.
Si ca c'est pas du dev, je sais pas ce que c'est !
Hahaha tu parles des codecs binaires dont ils ont gracieusement autorisé l'utilisation et des bouts de code qu'ils ont publié sous leur propre licence open source ?
Effectivement c'est une superbe contribution ! Permet moi de les applaudir chaudement.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par TImaniac (site web personnel) . Évalué à 4.
pourquoi tu gueules pas sur la fondation apache qui publie sous leur propre licence ?
la licence utilisé par MS est libre au sens OSI et FSF, c'est le principal.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par vida18 . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Bozo_le_clown . Évalué à 3.
Il en faudrait ... 2 pas plus :la GPL et la BSD
Et en plus on aurait plus besoin de l'OSI
Ce qu'il faut pas lire comme mauvaise foi lorsqu'il s'agit de taper sur M$.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Bozo_le_clown . Évalué à 2.
T'aurais pu mettre les balises, filou !
===> []
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par lasher . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Anonyme . Évalué à 2.
Il existe une implémentation de C# et .NET multiplateforme (y compris pour linux), opensource et faite par Microsoft?
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par collinm (site web personnel) . Évalué à 1.
java est maintenant un peu partout
www.solutions-norenda.com
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Anonyme . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par lasher . Évalué à 2.
La CDDL a (selon moi bien sûr) été créée uniquement pour empêcher Linux (qui est clairement le plus sérieux concurrent à l'Unix de Sun) d'intégrer « en l'état » les softs qui l'utilisent. Je ne critique pas le choix de Sun, qui se tient d'un point de vue « stratégique » : ils n'empêchent pas les OS « mineurs » (à l'exception d'OS X, certes) de l'utiliser, mais seulement le plus gros concurrent en face.
Cela étant dit je ne critique pas le choix de Sun, et je compte bien installer OpenSolaris d'ici peu sur ma machine (j'ai tout un tas de trucs à tester sur certains réglages systèmes qu'il permet et que ne permet pas -- encore ? -- Linux). Mais quand quelqu'un se moque de MS parce qu'ils ont fait « leur propre licence », je me permets juste de rappeler que des boites qui jusqu'à il n'y a pas longtemps faisait tout autant de propriétaire que MS ont aussi les leurs.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par kowalsky . Évalué à 2.
Il y a tout un tas d'archi qui ne sont supporté, il y en a même plus qui ne sont pas supporté que d'archi supporté !
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par pix (site web personnel) . Évalué à -1.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par BaptisteNew . Évalué à 10.
ça, c'est vrai pour Mono, mais pas pour Moonlight. cf le "covenant" de Microsoft et Novell, ça fout carrément les jetons ( http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...) ):
1) la protection n'est que temporaire
2) elle ne s'applique qu'à ceux qui téléchargent directement chez Novell. Les distros sont explicitement exclues (cf page de définitions)
OK, la priorité, c'est de combattre les brevets logiciels en général, mais semble-t-il, Microsoft en particulier cherche à faire usage des siens pour pourrir l'écosystème Linux.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par IsNotGood . Évalué à 7.
Pour mono oui. Pour Silverlight (ou Moonlight) non :
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
Il n'y a que MS et Novell qui peuvent distribuer. Bref, Moonlight n'est pas libre.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par cdeblesson . Évalué à 2.
Je suis exactement dans ce cas là : Des technologies intéressantes avec de sombres desseins derrière.
Si tu as apprécié le C#, regardes de ce coté : http://live.gnome.org/Vala qui me semble une très bonne idée.
Une plateforme de développement Gnome, avec un langage moderne.
Etant développeur java avec une forte envie de développer des applis natives linux, j'hésite entre Vala(jeune) et le nouveau Qt (abouti mais quel choc pour un gnomiste ;)
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par jiyuu . Évalué à 8.
Ça s'appelle l'illumination.
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
Qt pourrai à terme être le meilleur framework pour développer pour Gnome. Un plus gros choc encore, non?
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par Camille_B . Évalué à 2.
Espérons que le futur gtk3 soit à la hauteur ;)
# codec
Posté par bob le homard . Évalué à 6.
Je me suis rendu sur le site de VIdeo.Show et comme je n'avais pas le plugin, on me propose de télécharge le plugin Microsoft Silverlight.
Je suis naturellement redirigé vers la page de moonlight (c'est bien, je m'attendais à me retrouver sur la page windows).
le plugin s'installe facilement (plantage de firefox mais rien de bien méchant).
Je retourne à nouveau sur la page et il ne se passe rien.
En réalité, il semble que je doive installer des codecs Microsoft :
MICROSOFT SOFTWARE LICENSE TERMS
MICROSOFT MEDIA PACK 1.0
ONLY FOR USE WITH NOVELL'S MOONLIGHT 1.0 RUNNING IN AN INTERNET BROWSER
J'ai donc un peu de mal à comprendre le but de moonlight...
Est-il lié à microsoft ou peut on utiliser d'autres codecs à l'intérieur?
Si oui on aurait donc une technologie proche de flash mais ouverte. Ce qui en un sens serait pas mal...
(même si à mon avis le css, svg, et js sont beaucoup plus intéressant).
(ps : je n'ai pas installé les codecs, donc pas vu les videos ;o)
[^] # Re: codec
Posté par thedidouille . Évalué à 9.
bon écoute, t'es le bienvenue chez moi, enfin tu peux dormir dans le jardin quoi. Pour t'aider, on va te préter la tondeuse, ce sera plus confortable. Et vide les poubelles stp (il y a les restes de Cookie si t'as un pti creux, tu sais notre labradore), voilà, de rien.
[^] # Re: codec
Posté par David Carlier . Évalué à 2.
La vache il y a du boulot : http://silverlight.net/forums/t/58875.aspx
==> ok ok mais bon il neige quand même !
[^] # Re: codec
Posté par TImaniac (site web personnel) . Évalué à 3.
Tu peux compiler moonlight avec ffmpeg.
Le seul avantage du pack Microsoft, c'est qu'il est "légal" d'un point de vue licence/brevet pour les codecs WMV et VC-1.
Sinon effectivement ces codecs c'est du closed source pas bien du tout et bourrés de brevets.
# Une précision
Posté par Jb Evain (site web personnel) . Évalué à 3.
Il est aussi important de noter qu'il est toujours tout à fait possible de compiler son propre plugin en utilisant ffmpeg au lieu des codecs Microsoft.
A voir aussi, un plugin Firefox pour lire les fichiers wmv et wma directement, et qui utilise en fait Moonlight pour lire ces fichiers: http://abock.org/2009/02/11/announcing-moonshine-the-project(...) : Moonshine. Très pratique pour ceux qui n'ont pas réussi comme moi à faire marcher le support de Totem, et qui ont Moonlight d'installé.
(Et aussi c'est VB.NET, pas VB# :)
[^] # Re: Une précision
Posté par Littleboy . Évalué à 2.
# Un premier retour utilisateur
Posté par Aurélien Bompard (site web personnel) . Évalué à 10.
Je vous traduit vite-fait :
Je l'ai installé sur ma Fedora 10, et j'ai essayé de visiter des sites qui sont censés fonctionner avec Moonlight/Silverlight. Et voilà, Moonlight est en version 1 alors que Silverlight est en version 2. Donc c'est comme avec le projet Mono, qui est perpétuellement en train de courir après .NET. Je désinstalle.
[^] # Re: Un premier retour utilisateur
Posté par dadou92 . Évalué à 2.
L'effort est louable mais on est loin du compte. Je préfère encore JavaFX ou Flash. On se fout moins de ma gueule.
[^] # Re: Un premier retour utilisateur
Posté par bob le homard . Évalué à 3.
En gros, de créer sa propre technologie?
Je trouve cela très intéressant de pouvoir utiliser ffmepg pour y intégrer les codecs que l'on souhaite.
# dans 1 an ou deux
Posté par Anonyme . Évalué à 5.
Je ne vois vraiment pas en quoi il est intéressant de porter ce genre de technologie sous linux par la communauté et je remarque que encore une fois Microsoft ne fait pas elle même le travail pour notre OS. Elle supporte d'autre OS mais pour Linux il est clairement stipulé que cela doit être interdit de fournir un logiciel de la même génération que ceux disponibles sur les autres OS.
# oups
Posté par Anonyme . Évalué à -3.
donc je disais Moonlight sera au niveau de silverlight2 dans 2 ans.
# Intéret de Silverlight ?
Posté par Adrien . Évalué à 6.
D'où ma question : quel est l'intérêt de développer un truc avec Silverlight, ou Moonlight ?
On va retomber dans tous les problèmes de flash, en pire puisque c'est loin d'être une norme de facto.
Qu'apporte Silverlight par rapport à ces concurrents, notamment par rapport aux standards du web ?
[^] # Re: Intéret de Silverlight ?
Posté par Lutin . Évalué à 6.
Sur internet, c'est Noël tous les jours.
[^] # Re: Intéret de Silverlight ?
Posté par TImaniac (site web personnel) . Évalué à 4.
La même chose que Flash :
- la possibilité pour le programmeur d'utiliser autre chose que les "standards" du W3C qui traînent des boulets derrière eux, à commencer par Javascript avec sa grammaire et ses perfs de merde (malgré tous les efforts des navigateurs).
- la possibilité d'utiliser des bibliothèques multimédias : Vidéo, Audio, 2D, 3D, le tout de manière unifié et intégré. Même en aggrégant tous les standards du W3C ont obtient pas la même couverture fonctionnelle. Suffit de regarder les possibilités en matière de streaming vidéo qui arrive dans Flash10 ou Silverlight pour voir qu'en la matière ce que prévoit le W3C dans HTML5 est totalement à la ramasse.
Évidemment y'a les lots d'inconvénients qui contre-balance largement ces avantages. Mais chacun utilise ce dont il a besoin hein.
L'intérêt de Silverlight par rapport à Flash ?
- la possibilité d'utiliser le javascript de merde si le programmeur en a encore envie (Silverlight 1.0) tout en ayant accès aux possibilités multimédias que n'offrent pas les standards W3C.
- beaucoup plus naturelle pour l'ensemble des programmeurs MS qui retrouvent leurs langages, leurs outils avec toute l'intégration client/serveur qui va bien made-in-MS.
Là encore, Flash a bien d'autres avantages : plus de fonctionnalités, support H264, déjà déployé, etc.
PS : j'utilise pas Silverlight et j'utilise Flash que quand j'ai pas le choix, donc pas taper, j'essai juste d'expliquer.
[^] # Re: Intéret de Silverlight ?
Posté par Psychofox (Mastodon) . Évalué à 9.
- la possibilité pour le programmeur d'utiliser autre chose que les "standards" du W3C qui traînent des boulets derrière eux, à commencer par Javascript avec sa grammaire et ses perfs de merde (malgré tous les efforts des navigateurs).
Je veux pas dire, mais flash, question perfs, c'est autant la merde (et pas seulement avec la version linux pourrie).
[^] # Re: Intéret de Silverlight ?
Posté par FantastIX . Évalué à 4.
Je dirais pas "pire" mais "bien pire" en fait. Ce sont les mêmes problèmes, multipliés par autant de versions et de technologies différentes.
Résumons.
Au départ, y avait des standards HTML (caducs, oui sans doute) qui ne tenaient pas vraiment compte des possibilités technologiques. Ça a au moins permis une chose: l'avènement des anti-standardistes -- «les standards, c'est bon que si tout le monde s'en sert» et autres conneries du genre.
Puis il y a eu Flash -- parce que Flash résolvait itou les problèmes de compatibilité des navigateurs. Mais à l'époque, il n'y en avait que deux! (Netscape et Internet Explorer.)
Et il y eut aussi Java, multiplateforme.
Puis il y a eu de vrais standards HTML, tenant compte des capacités technologiques des navigateurs. Il y a eu aussi du coup encore plus de navigateurs.
Ensuite il y a eu encore plus de version de Flash.
Ensuite il y a eu Silverlight.
Puis il y aura encore plus de versions de Silverlight.
--- Fin de l'histoire?
J'ai un gros doute, là...
Ça donne quoi, ce foutware?
Maintenant qu'on n'a plus seulement un, ni deux mais au moins trois médias possibles (Java, Flash, Silverlight, tout aussi incompatibles entre eux, cela va de soi) en plus de HTML, on retrouve les mêmes problèmes de version mais en plus on divisera encore plus l'audience du Web. Le premier point me fait pisser de rire, rien qu'en songeant à tous ceux qui ont la mémoire courte. Je m'explique sur le deuxième point.
Ce n'est pas Flash qui a incité à fournir des versions alternatives des sites «Flashisés», que du contraire. Ensuite il y a toujours eu des réfractaires à l'utilisation des standards (ouverts qui plus est) et il y en aura toujours. C'est juste dommage qu'ils se soient fait une place sur la toile et soient adulés. Bref.
Par pure politesse, il convient de fournir une version alternative à tous ceux qui ne possèdent pas le lecteur du média approprié. Ne pas le faire revient à en léser certains. Maintenant, ça se complique davantage! Et quoi encore? On fait une version HTML, une version Flash, une version Java et une Silverlight? Ça va pas la tête?
Surtout que si on fait une version fonctionnelle en HTML, conforme, les trois autres sont inutiles. Et HTML 5 est de nouveau là pour le démontrer. Tout ça sans [trop] se fatiguer: on contente 100% des visiteurs au lieu de faire une sélection purement subjective et sans pitié.
Or on a accepté ce principe lorsqu'on parle de navigateurs! Pourquoi les utilisateurs de Firefox (et Mozilla et Safari et Konqueror et...) seraient-ils lésés par rapport à ceux de MSIE?
Ben, non seulement c'est pas résolu pour les Flashistes mais ça continue et ça empire avec Silverlight. Les règles de bon sens finissent généralement aux oubliettes avec les fanatiques peu scrupuleux de ces technologies. Un peu comme de placer des contrôles sur une boîte sans se préoccuper de la séquence de sélection au clavier. Il y a ceux qui ne savent pas et ceux qui font autrement...
Au pire, les sites seront d'une inaccessibilité totale... Les uns n'admettant pas faire des efforts pour les autres, un site sera soit (Silver|Moon)light soit Flash (et si t'as pas la bonne version, ben tant pis pour ta pomme) et basta. Moralité: encore plus de ségrégation numérique. Ça fait «ringard» de pouvoir modifier son code avec juste un éditeur de texte ou quoi? Du coup, j'ai décidé de rester «Has-Been»...
Pondre du code HTML conforme c'est un peu comme s'ouvrir l'esprit. Pas besoin de regorger d'imagination pour trouver une solution qui soit acceptable pour tout le monde. C'est aussi se donner des limites raisonnables. Se creuser les méninges au lieu de céder à [ce qui se fait passer pour de] la facilité, c'est aussi faire preuve de jugeote.
Je n'ai ni Flash, ni Gnash (je souhaite encore longue vie à ce projet malgré tout, merci d'exister) ni Silverlight. Je ne m'en porte pas plus mal. Je suis chez moi et j'ouvre ma porte à qui je veux, c'est encore mon droit.
Voilà tout le bien que je pense de ces technologies ségrégationnistes et séparatistes. On ferait bien de foutre tout ça à la poubelle et de reprendre un peu ses esprits!
Au moins, je ne suis plus tombé sur un seul site ayant besoin de Java. Faut croire qu'il a disparu des pages ou est en voie de disparition et c'est tant mieux. Un monstre se barre mais en voilà un autre, par contre...
[^] # Re: Intéret de Silverlight ?
Posté par FantastIX . Évalué à 0.
[^] # Re: Intéret de Silverlight ?
Posté par timid . Évalué à 2.
Maintenant prend un développeur web qui veut foutre une animation vectorielle interactive sur son site, il a quoi comme choix ?
SVG ? Ca ne marche pas par défaut sous IE, sous konqueror le rendu est mauvais, sous firefox ca marche mais ca se traine méchemment (pas testé avec les bétas de la version 3.1)
Concrètement, il reste quoi comme alternative libre ?
[^] # Re: Intéret de Silverlight ?
Posté par Camille_B . Évalué à 2.
# Moonlight est distribué sous la licence LGPL v2
Posté par IsNotGood . Évalué à 5.
Petite précision, MS (avec Novell) utilise une faille de la GPL. Avec l'accord entre MS et Novell, même si Moonlight est LGPL, Moonlight n'est pas libre (pourré de brevets, comme Silverlight).
Notons bien ça :
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPLv3 or a Similar License.
La GPL v3 est notamment faite pour éviter le piège de l'accord entre MS et Novell. Et, "comme par hazard", il est interdit de mettre en oeuvre Silverlight avec la (L)GPL v3.
Sacré MS, Sacré Novell.
N'utilisez pas Silverlight, ni Moonlight.
Il y a Flash. Certes il n'y a pas de mise en oeuvre libre et de bonne qualité (c'est discutable). A ma connaissance, ce qui est proprio dans Flash est la vidéo (flv), mais rien d'autre. On peut "réver" d'un flash libre avec support Theora.
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par TImaniac (site web personnel) . Évalué à 1.
l est interdit de mettre en oeuvre Silverlight avec la (L)GPL v3.
N'importe quoi. Ce document dit uniquement que MS s'engage à ne pas attaquer Novell pour distribuer Moonlight, tant que ce ne sont pas des licences de type GPLv3. En imaginant un fork ou un changement de licence de la part de Novell, l'engage de MS ne tient plus, c'est tout. Et Moonlight devient aussi "nue" niveau protection que l'ensemble des autres logiciels libres. Ou que Flash, ou que n'importe quel logiciel non couvert par cet accord.
A ma connaissance, ce qui est proprio dans Flash est la vidéo (flv), mais rien d'autre.
Un peu comme moonlight quoi.
On peut "réver" d'un flash libre avec support Theora.
Et c'est bien connu, Flash et Theora sont des technos qui sont reconnus mondialement pour ne pas être sous l'épée de Damoclès d'un brevet enregistré quelque part dans le monde.
PS : tu compiles moonlight avec ffmeg, ayé tu l'as ton support theora.
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par Adrien . Évalué à 4.
J'aime beaucoup la rhétorique Microsoft :
« Moonlight c'est libre ?
– Oui pas de soucis, c'est même Novell qui le fait !
– Je peux faire un fork en GPLv3 ?
– oui aucun soucis. Bon je pourrais t'attaquer après avec mes brevets, mais ce n'est pas grave. Tu me connais jamais je ne ferais une chose pareil :)
– Merci beaucoup M. Microsoft, vous êtes trop bon avec les libristes. »
Microsoft, l'art de la dissimulation et de la tromperie :)
Une vraie question : quelle est la motivation des dev de Novell pour supporter Moonlight ? Idéologiquement les libristes ne peuvent que cracher dessus, Silverlight est quasiment inconnu de tous… C'est bizarre cette envie de Novell d'aider le déploiement de MS sous linux.
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par TImaniac (site web personnel) . Évalué à 4.
Encore une fois, rien ne t'empêche d'ignorer tout simplement cet accord entre Novell et MS qui ne regarde que eux. Y'a pas de piège ou quoi que ce soit, tu regardes pas leurs accords, ca concerne uniquement MS, Novell, et leurs clients respectifs.
quelle est la motivation des dev de Novell pour supporter Moonlight ?
Ben c'est une alternative à Flash. Déjà rien que pour ca, ca mérite d'exister, parcque ca court pas les rues.
Ensuite sinon Novell supporte Moonlight, c'est juste parcque la version suivante s'appui sur .NET, et donc Mono. Ca donne une légitimité supplémentaire au projet Mono (qui est reconnu officiellement par MS pour le coup).
Je suppose que c'est également un pari sur l'avenir : Novell fait le pari que la techno Silverlight pourrait se démocratiser, et qu'il est donc important d'avoir une alternative libre sous linux comme ils ont fait le même pari pour Mono.
Idéologiquement les libristes ne peuvent que cracher dessus,
Juste les anti-MS, pas tous les libristes. On les entend beaucoup parcqu'ils gueulent tout le temps, mais ca veut pas dire qu'ils sont majoritaires.
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par Camille_B . Évalué à 5.
Et même s'ils l'étaient, je ne vois pas en quoi ils auraient raison :D
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par benoar . Évalué à 2.
[^] # Re: Moonlight est distribué sous la licence LGPL v2
Posté par GeneralZod . Évalué à 1.
C'est très bien de la part d'Adobe (mais insuffissant comme tu l'as justement fait remarqué), mais la portée de ce geste reste beaucoup plus limité que tu ne sembles le croire. Je te laisse jeter un oeil à la réaction de Benjamin Otte le mainteneur actuel de swfdec à ce propos :
http://lists.freedesktop.org/archives/swfdec/2008-May/001459(...)
# Pendant ce temps là...
Posté par Nonolapéro . Évalué à 4.
http://info.francetelevisions.fr/
Il y a un billet [1] à ce sujet sur le blog Formats Ouverts
En tout cas j'ai découvert le billet aujourd'hui et quelques instants plus tard je vois la dépêche pour l'annonce de la sortie de Moonlight. C'est parfois drôle les coïncidences.
[1] http://formats-ouverts.org/blog/2009/02/02/1862-l-autre-revo(...)
# Le sage montre la lune et l'idiot regarde le doigt
Posté par GeneralZod . Évalué à 4.
Un exemple bien connu étant le projet GNU, GNU s'est inspiré d'Unix, le but étant de préserver une intéropérabilité avec l'existant, de faciliter le portage de logiciels (souvent de très bonne qualité), d'attirer les développeurs. Et GNU a réussi cela en apportant ses propres améliorations et en évitant le piège de la bête imitation. Les boites derrière les Unix propriétaires dans les années 80 n'étaient pas plus tendre que le Microsoft d'aujourd'hui.
Mono/Moonlight a pour but d'implémenter certes des technologies Microsoft qui sont reconnaissons-le pas mal chiadés. Oui, Mono/Moonlight est légérement à la traine derrière l'implémentation de Microsoft [1] mais Mono ne se limite pas à "copier" .Net. Il y a d'abord les bibliothèques spécifiques qui permettent qu'on puisse écrire une application parfaitement intégré aux environnements GNOME, OS X (et bientôt KDE via Qyoto), d'autres qui n'ont aucun équivalent dans le framework .Net (MonoTorrent, Mono.Simd, etc ...). Mono va également nettement plus loin que .Net grâce à son côté multiplateforme.
Il explose au niveau de l'embarqué (notamment sur iPhone grâce à la possibilité de compiler en natif), dans le domaine ludique (Second Life, des jeux sur Wii, etc ...), pour du développement multiplateforme ou spécifique, il est est plus attractif que .Net
Bref, Mono a fait ses preuves en tant que plateforme indépendamment de .Net, la compatibilité avec celui-ci étant surtout un bonus. Mono offre des outils pour faciliter le portage des applications (l'excellent Gendarme), ça encourage les développeurs à s'intéresser aux plateformes libres.
Quant à Moonlight, il ne se limite pas à une bête implémentation de Silverlight, il a même été conçu pour être utilisable en dehors de Mono comme l'a souligné l'auteur de la dépêche. On peut l'utiliser dans une application Gtk+ indépendamment de Mono, les deloppeurs de Novell ont même écrits un petit framework permettant l'écriture de desklets.
http://tirania.org/blog/archive/2008/Apr-17.html
Reste le problème des brevets logiciels.
D'un côté, Microsoft collabore activement avec l'équipe Mono (même avant l'infâme accord avec Novell), de l'autre, ils entretiennent une certaine confusion autour de Mono.
Sans rentrer dans les détails, Mono (et bon nombre de projets libres dont le noyau Linux) est protégé par le consortium OIN qui dispose d'un portefeuille de brevets conséquents. Microsoft n'a clairement pas intérêt à se frotter à OIN et leur stratégie consiste principalement à maintenir une longueur d'avance sur Mono.
Après, reste à éclaircir le cas de Moonlight, est-il protégé par OIN ? est-il librement implémentable ? Quel est la légalité de l'utilisation des codecs microsoft ? y-a-t-il une alternative[2] ?
En tant que framework RIA, Moonlight me laisse dubitatif, d'une part il y a des technologies standards qui n'attendent qu'un peu d'amour (html5, svg, etc ...), de l'autre, un marché fortement concurrentiel flex+flash (supaire -_-), JavaFX (pas encore libéré ?), un silverlight bardé de DRMs (et une politique Microsoft mal définie vis à vis de Moonlight).
En revanche, c'est une technologie relativement sympa sur le bureau et la créativité des développeurs réussira surement à lui donner une place.
Avant de troller, attendons de voir comment évoluera la situation (et Moonlight) !
[1] Ce n'est pas systèmatiquement le cas, si je me souviens bien, Mono avait implémenté les generics avant Microsoft. Le modèle bazar de Mono lui permettant d'être un poil plus réactif que la cathédrale de Microsoft qui compense le fait que Mono c'est une dizaine de développeurs à temps pleins, .Net c'est probablement 10 à 50 fois plus.
[2] la réponse rapide est oui, Moonlight utilisait ffmpeg à ses débuts mais Novell n'a pas le droit de redistribuer Moonlight + ffmpeg. Je ne me suis pas penché sur la question, mais il semblerait que cette possibilité ait été conservée dans le code de Moonlight.
http://tirania.org/blog/archive/2007/Sep-05.html
[^] # Re: Le sage montre la lune et l'idiot regarde le doigt
Posté par dadou92 . Évalué à 2.
"The JavaFX compiler, parts of the graphics libraries and tools are available now from the OpenJFX (http://openjfx.org) web site, under the GPL 2.0 open source license."
# Au secours ! !! FranceTV s'y mets
Posté par memeteau michel (site web personnel) . Évalué à -1.
http://info.francetelevisions.fr/
on touches vraiment le fond ......
personne n'as de contact avec les developpeurs de ce portail ?
Linux sur PC disponible pour tous http://shop.ekimia.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.